Generate the Norwegian equivalent to social security numbers - follow-up
Here are some suggestions which may help you improve your code.

Don't abuse using namespace std

Putting using namespace std within your program is generally a bad habit that you'd do well to avoid.  

Use the appropriate #includes

The code uses the strlen() function a number of places but does not #include &lt;cstring&gt; which is where that library function is defined.

Eliminate unused variables

This code declares main with arguments argc and argv in the usual way, but neither argc nor argv are actually used.  This could be addressed by either declaring int main() or by modifying the code to actually use the variables.  There is a third way, which is to declare it as int main(int, char *[]) but this is not recommended because it's a bit confusing to read.

Separate I/O from object creation

The Date class should not do I/O directly to std::cout and std::cin.  Better design would be to create a custom inserter and custom extractor for the class to allow but not to force I/O operations for the creation of an object.  For example, your Date class might have the following two definitions:

std::ostream &amp;operator&lt;&lt;(std::operator &amp;out, const Date &amp;d);
std::istream &amp;operator&gt;&gt;(std::operator &amp;in, Date &amp;d);


The same is true of the KontrollSiffer class.

Perform better error checking for user input

As it is currently written, one can type in "Norway" as the Date and the code proceeds to proces that input as though it were a valid date, producing invalid results.  Better would be to include more checking beyond just whether the string is 6 characters long.

Prefer std::string to raw char *

The Date class uses a raw char * but would probably be better served by using std::string in this context.  

Use aggregation rather than inheritance for composition

The inheritance mechanism is generally suited for "is-a" relationships.  For example, if one had a Birthday class, it might reasonably be derived from a Date base class, since a Birthday is a Date.  However, an IndividSiffer is not really a Date, but is rather constructed from one, so a better design might either have a Date as a private instance variable with the IndividSiffer class or to simply accept a const Date &amp; variable as an argument to an IndividSiffer constructor.

Don't keep variables you don't need

The ans variable is only actually used within the askForDate() routine, so there's no reason to keep it as part of the Date class.  Better would be to declare it as a local variable within the askForDate() function.

Prefer to avoid using new and delete directly

The ans variable within the Date::askForDate() function is small enough to easily fit on the stack, so rather than using new to allocate it, better would be to declare it locally within the askForDate function as:

char ans[DATE_LENGTH];


That way, it is automatically created with the correct length and then discarded when the function is complete.  

Think carefully about static variables

The code for IndividSiffer::individSiffer() uses a static variable individ which is a problem.  When you create two IndividSiffer instances in the same program, only the first one will have the variable initialized.  That is because a static variable only gets initialized once before the program is run.  This very greatly limits the use of these classes.

Consider using a standard container

The effect of the KontrollSiffer class is to create and print 500 individual numbers.  Rather than simply print and discard them, it might be more sensible for general use to create a collection of them, perhaps in a std::vector&lt;IndividSiffer&gt; for example.

Omit return 0

If your program completes successfully, the return 0 at the end of main() will be generated automatically, so it's not needed in C++ programs.